NES Classic: The Legend of Zelda - CRACK EXPLAINED.
---------------------------------------------------

Welcome to the first crack document for The Legend of Zelda, written by neimod.


1. Emulator detection
---------------------
The NES classics introduce a new way of protection,
it can detect if it is ran on an emulator, and it will "idle" if an emulator is found.

This is the function for detecting emulators:

-> 06000264  e28fe008 add lr, pc, #0x8
-> 06000268  e51f0010 ldr r0, [$06000260] (=$e3a01000)
-> 0600026c  e58e0000 str r0, [lr]
-> 06000270  e3a010ff mov r1, #0xff
-> 06000274  e3a010ff mov r1, #0xff

This unique piece of code actually works; I will explain:

06000264  e28fe008 add lr, pc, #0x8
-> Grab a pointer to 06000274, store it in register lr.

06000268  e51f0010 ldr r0, [$06000260] (=$e3a01000)
-> Load r0 with the binary opcode ("mov r1, #0").

0600026c  e58e0000 str r0, [lr]
-> Overwrite "06000274  e3a010ff mov r1, #0xff" with: "mov r1, #0".
Disassembly will now be:
-> 06000264  e28fe008 add lr, pc, #0x8
-> 06000268  e51f0010 ldr r0, [$06000260] (=$e3a01000)
-> 0600026c  e58e0000 str r0, [lr]
-> 06000270  e3a010ff mov r1, #0xff
-> 06000274  e3a01000 mov r1, #0x00     <--- overwritten

06000270  e3a010ff mov r1, #0xff
-> Set r1 to 0xff

Now here is the catch:
-> 06000274  e3a01000 mov r1, #0x00

At executing the instruction at 06000274, an emulator will load the instruction at 06000274, currently being "mov r1, #0x00".
-> This will set r1 to 0x00.
Now, on a REAL GBA, the instruction at 06000274 was ALREADY FETCHED, so a REAL GBA will execute the original instruction, being "mov r1, #0xff".
-> This will set r1 to 0xff.

And so, if r1 equals 0x00, the game is run on emulator, if r1 equals 0xff, the game is run on a real GBA.

This has been tested on Rascalboy Advance, Visualboy Advance, and it works.
DreamGBA however is not fooled, and emulates this behaviour properly.


2. Sram detection
-----------------
This technique has been blatantly overused in the Dragonball Z series, and in Iridion 2.
And a somewhat similar routine is used in the NES Classics.

This is the function for detecting Sram:

-> 02f34b54  26e0 mov r6, #0xe0
-> 02f34b56  0536 lsl r6, r6, #0x14
-> 02f34b58  2400 mov r4, #0x0
-> 02f34b5a  7034 strb r4, [r6, #0x0]
-> 02f34b5c  7074 strb r4, [r6, #0x1]
-> 02f34b5e  7830 ldrb r0, [r6, #0x0]
-> 02f34b60  2800 cmp r0, #0x0
-> 02f34b62  d113 bne $02f34b8c
-> 02f34b64  7870 ldrb r0, [r6, #0x1]
-> 02f34b66  2800 cmp r0, #0x0
-> 02f34b68  d110 bne $02f34b8c
-> 02f34b6a  4d2b ldr r5, [$02f34c18] (=$0000ffff)
-> 02f34b6c  3401 add r4, #0x1
-> 02f34b6e  42ac cmp r4, r5
-> 02f34b70  d80c bhi $02f34b8c
-> 02f34b72  7034 strb r4, [r6, #0x0]
-> 02f34b74  0a22 lsr r2, r4, #0x08
-> 02f34b76  7072 strb r2, [r6, #0x1]
-> 02f34b78  7831 ldrb r1, [r6, #0x0]
-> 02f34b7a  23ff mov r3, #0xff
-> 02f34b7c  1c20 add r0, r4, #0x0
-> 02f34b7e  4018 and r0, r3
-> 02f34b80  4281 cmp r1, r0
-> 02f34b82  d103 bne $02f34b8c
-> 02f34b84  7870 ldrb r0, [r6, #0x1]
-> 02f34b86  401a and r2, r3
-> 02f34b88  4290 cmp r0, r2
-> 02f34b8a  d0ef beq $02f34b6c

This might be what rough on the eyes and brain, so here's the C version of the previous assembler code:

for(int i = 0; i < 0x10000; i++)
{
	Sram[0] = i & 0xff;
	Sram[1] = (i >> 8) & 0xff;
	if (Sram[0] != i & 0xff)
		break;
	if (Sram[1] != (i>>8) & 0xff)
		break;
}

This function tries to write a halfword to save memory, and if the value read back equals the value written, SRAM is detected.

Obviously, when the save chip present in the game cartridge is EEPROM, one would need to first prepare
the save chip for writing, before actual writing can take place.
If you try to write data to EEPROM, before it is prepared, writing will fail.

Now, on the other hand, when the save chip present in the game cartridge is SRAM, one can write directly to it, without preparation.

Both EEPROM and SRAM are mapped into the same memory location: 0x0e000000.

So, writing to an EEPROM save chip would fail, while it is successful at writing to SRAM.


3. Size detection
-----------------
This is a somewhat annoying function, and it is made to delay the pad updater.

-> 03003afc  e59d0960 ldr r0, [sp, #0x960]
-> 03003b00  e1a00600 mov r0, r0, lsl #0x0c
-> 03003b04  e3a01302 mov r1, #0x8000000
-> 03003b08  e7d12620 ldrb r2, [r1, r0, lsr #0x0c]
-> 03003b0c  e2811603 add r1, r1, #0x300000
-> 03003b10  e7d1e620 ldrb lr, [r1, r0, lsr #0x0c]
-> 03003b14  e032200e eors r2, r2, lr
-> 03003b18  e28d0b02 add r0, sp, #0x800
-> 03003b1c  e2801008 add r1, r0, #0x8
-> 03003b20  e8b04004 ldmia r0!, {r2,lr}
-> 03003b24  08a14004 stmeqia r1!, {r2,lr}

03003afc  e59d0960 ldr r0, [sp, #0x960]
03003b00  e1a00600 mov r0, r0, lsl #0x0c
-> Set r0 to an updated index.

03003b08  e7d12620 ldrb r2, [r1, r0, lsr #0x0c]
-> Load a byte from ROM[index], store it to r2.

03003b10  e7d1e620 ldrb lr, [r1, r0, lsr #0x0c]
-> Load a byte from ROM[index + 0x300000], and store it to lr.

03003b14  e032200e eors r2, r2, lr
-> Xor ROM[index] with ROM[index + 0x300000], and set CPSR flags.

03003b24  08a14004 stmeqia r1!, {r2,lr}
-> If ROM[index] ^ ROM[index + 0x300000] equals 0, then the pad data is updated.

The game reads the current pad value every frame, and writes it to a temporary storage location.
It then compares a byte from ROM[index] with ROM[index + 0x300000], and see if they are identical.

If they are not identical, pad is NOT updated this frame, if they are, the data from this temporary storage location is written to the memory location
where the game will react immediatly to the new pad value.

Obviously, there will be at certain points, where the bytes are identical, and that's why the pad will be updated at those frames.


4. Optional eeprom to sram fix
------------------------------
After the Sram detection has been fixed, it is now safe to reprogram the EEPROM writing/reading routines to work with sram.
If sram was detected, the game will display an error message, and will not boot.
Now, if you fixed that, the game will still not boot with sram save chip.

The game tries to read a Zelda header from save memory, if it is not found, it tries to write it.
It then tries to read it again, and if there is still no Zelda header found, the same error message will appear again.
So, we must make sure writing and reading works on sram (because most flashcarts support sram).

So, this takes us to a closer look at the Nintendo Library for the EEPROM programming interface.
There are 4 important functions to programming EEPROM save data:

- Identify_EEPROM();
- Program_EEPROM(sector, src);
- Read_EEPROM(sector, dst);
- Verify_EEPROM();

Nintendo tries to fool you yet again. There is a typically uncompressed Nintendo EEPROM Library present in the ROM, but it is fake.
This library is NOT used at all in the game.
The game has a hidden Nintendo EEPROM library, which is compressed. Very sneaky Nintendo.

On to the EEPROM routines.
The Identify and Verify routines are pretty harmless.
Identify_EEPROM will always return success, regardless if sram is present.
Verify_EEPROM should work as it should, because it simply checks one memory block with another.

The Progam_EEPROM function expects as first parameter the sector number, and as second parameter a pointer to the source data.
When calling Program_EEPROM, it will read 8 bytes from src and write it to save memory located at sector.
Thus, the real offset to save memory is sector*8.
The same interface is applied to Read_EEPROM, but for reading from eeprom.

Now we know how the EEPROM interface works, now you only need to know the location of these functions, so we can rewrite them.

Identify_EEPROM:
02f329d4  b500 push {lr}
02f329d6  0400 lsl r0, r0, #0x10
02f329d8  0c00 lsr r0, r0, #0x10
02f329da  2200 mov r2, #0x0
02f329dc  2804 cmp r0, #0x4
02f329de  d107 bne $02f329f0
02f329e0  4901 ldr r1, [$02f329e8] (=$03006750)
02f329e2  4802 ldr r0, [$02f329ec] (=$02f32d64)
02f329e4  6008 str r0, [r1, #0x0]
02f329e6  e011 b $02f32a0c
...

Program_EEPROM:
02f32b60  b5f0 push {r4-r7,lr}
02f32b62  b0ac add sp, -#0xb0
02f32b64  1c0d add r5, r1, #0x0
02f32b66  0400 lsl r0, r0, #0x10
02f32b68  0c01 lsr r1, r0, #0x10
02f32b6a  0612 lsl r2, r2, #0x18
02f32b6c  0e17 lsr r7, r2, #0x18
02f32b6e  4803 ldr r0, [$02f32b7c] (=$03006750)
02f32b70  6800 ldr r0, [r0, #0x0]
02f32b72  8880 ldrh r0, [r0, #0x4]
02f32b74  4281 cmp r1, r0
...

Read_EEPROM:
02f32a9c  b570 push {r4-r6,lr}
02f32a9e  b0a2 add sp, -#0x88
02f32aa0  1c0d add r5, r1, #0x0
02f32aa2  0400 lsl r0, r0, #0x10
02f32aa4  0c03 lsr r3, r0, #0x10
02f32aa6  4803 ldr r0, [$02f32ab4] (=$03006750)
02f32aa8  6800 ldr r0, [r0, #0x0]
02f32aaa  8880 ldrh r0, [r0, #0x4]
02f32aac  4283 cmp r3, r0
02f32aae  d305 bcc $02f32abc
02f32ab0  4801 ldr r0, [$02f32ab8] (=$000080ff)
02f32ab2  e044 b $02f32b3e
02f32ab4  6750 str r0, [r2, #0x74]
02f32ab6  0300 lsl r0, r0, #0x0c
02f32ab8  80ff strh r7, [r7, #0x6]
02f32aba  0000 lsl r0, r0, #0x00
02f32abc  4822 ldr r0, [$02f32b48] (=$03006750)
02f32abe  1c06 add r6, r0, #0x0
02f32ac0  6800 ldr r0, [r0, #0x0]
02f32ac2  7a01 ldrb r1, [r0, #0x8]
... 


Here's a quick C version for Read_EEPROM, fixed to work with sram:
Read_EEPROM_SRAM_Fixed(u32 sector, u8 *dst)
{
	for(int i = 0; i < 8; i++)
		*dst++ = Sram[sector*8 + i];

}

And ofcourse, here's a quick C version for Program_EEPROM, fixed to work with sram:
Program_EEPROM_SRAM_Fixed(u32 sector, u8 *src)
{
	for(int i = 0; i < 8; i++)
		Sram[sector*8 + i] = *src++;

}

And that's it! Pretty simple eh?

Until the next...